1. Field of the Invention
The present invention relates to a computer-implemented method for debugging a circuit design with a testbench in the field of integrated circuit (IC) design, and in particular to a method for debugging the testbench using post-processing approach.
2. Description of the Prior Art
Post-processing approach is often used for hardware debugging since saved simulation results are sufficient to provide hardware engineers with the ability to debug the hardware design. During hardware simulation, signal values at circuit nodes will be recorded for debugging throughout the entire simulation. Moreover, signal values only change at discrete simulation times. Therefore, during hardware simulation, signal value changes are often saved in files (also called dump files) in industry standard formats, such as Value Change Dump (VCD) or Fast Signal Database (FSDB). During post-processing debugging, waveform viewers are often used to read VCD or FSDB files to display signal value changes with respect to simulation times for helping users debug the behavior of the hardware design conveniently.
The testbench written in high level language, such as SystemVerilog or C++, however, is more like traditional software in that objects can be created and deleted dynamically; variable values can change again and again while the simulation time stays unchanged; and functions and tasks (which will be collectively referred to as “subroutines” hereafter) can be called recursively if so desired. Using the conventional way of hardware debugging, such as signal value dumps and waveform viewing, is inadequate for debugging the testbench. Therefore, it is better to use a software debugging approach to debug the test bench, much like using an interactive debugger such as “GNU Debugger (GDB)” to debug a C++ program. While it's possible to do interactive debugging for the testbench, users often suffer from poor performance due to the simulator spending a long time evaluating the hardware part.
Therefore, in conventional hardware simulation and debugging, it is very difficult to integrate both hardware debugging and testbench debugging together due to their intrinsic differences in operations.
SystemVerilog provides an advantage in addressing the verification complexity challenge. However, there is a gap for IC designers when it comes to the debug and analysis of SystemVerilog testbench (SVTB). The accepted “dumpvars-based” techniques are not practical for the object-oriented testbench. Nevertheless, engineers do need to know what the testbench is doing at any given point in time. Thus far, engineers have been forced to revert to low-level, text-based message logging and subsequent manual analysis of the resulting text log files. Logging—the process of recording the history—has been widely used in systems and software environments.
Most SystemVerilog libraries used today provide some built-in utilities to log messages generated from the testbench into a low-level text files that can be analyzed after simulation, engineers then manually correlate the testbench data to the design activity in order to debug the testbench. Therefore, this is a painful and ineffective approach to debug the testbench itself by using the logging messages alone.
U.S. Pat. No. 6,934,935 entitled “Method and Apparatus for Accurate Profiling of Computer Programs” discloses a method and apparatus for profiling the execution of a computer program, including the actual CPU cycles spent in each function and the caller-callee (i.e., who-calls-who) relationships. To collect the runtime data, it has to insert software codes into the program. The collected data can be used to analyze the performance of the program and provide hints as to which parts of the program can be optimized to speed up the execution of the program. However, in testbench code executions, the focus is not on the CPU cycles spent in each subroutine. Consequently, the disclosure of U.S. Pat. No. 6,934,935 is aimed at evaluating software performance, but not debugging a testbench.
Therefore, what is needed is a technique to record the behavior of SVTB functions and tasks at the same time with the activities of the DUT so that the history of the testbench execution can be correlated to the DUT in a simulation by using the same simulation time stamps. Then, the recorded information can be used to provide post-processing debugging capabilities to users so that the DUT and SVTB can be debugged together effectively and efficiently.